RIG Exploit Kit – Diving Deeper into the Infrastructure
Following our previous blog post about the leaking of the RIG exploit kit's source code, we dug deeper into the architecture that facilitates the massive infections using RIG. The screen shot below diagrams RIG's infrastructure.
RIG Exploit Kit Infrastructure
Most commonly we see only the one end of this rabbit hole--the compromised site and the proxy server. Below we will detail what happens behind the scenes during the infection and explain how RIG customers use it to deploy their infection campaigns.
We weren't kidding about digging deep, so grab a cup of coffee because you may be here a while.
First thing first
RIG's infrastructure might look complicated, but it's rather straightforward for the customer who simply wants to infect victims and generate revenue. So, we'll start with the basics. For the purposes of our analysis, we'll take the perspective of a RIG customer that already maintains a backdoor on a popular web site and now wants to monetize that traffic. First, the RIG customer needs a URL to which they can redirect the traffic to exploit victims' machines.
RIG customer API - "api.php"
RIG Customer API ("Get Link" button - generates customer's specific URL)
In order to infect victims, the RIG customer has to choose a payload and upload it through the admin panel – but we won't focus on this. Once the RIG customer uploads the payload, it makes sense that the next step would be pointing victims to the infection page. However, in order to evade detection by web filters and URL lists, the landing page needs to update regularly. RIG provides an API for this purpose that creates new, valid infection URLs on demand. Clicking on the "Get Link" button in the interface pictured above will provide the API URL. The URL will be in the following format:
hxxp://[RIG-Instance-Server]/api.php?apitoken=[API TOKEN]
The "API TOKEN" at the end of the URL is a unique key that combines the user's ID with the current "Flow ID" (pictured in Figure 2 below), serializes the combination and encrypts it using RC4 with a private key configurable only by the main RIG administrator. Each RIG user can have up to 2 distinct flows, which allows for infections via different payloads for each flow.
Code snippet that appends the API token
The PROXY Layer
The output of the URL above is the "PROXY" URL which functions as the "infection page". Here is an example of the structure of the "PROXY" URL:
hxxp://[PROXY Server]/proxy.php?PHPSSESID=njrMNruDMlmbScafcaqfH7sWaBLPThnJkpDZw-4|OTMxOGYwMjdkZTMxOGFmN2M5OWZkMDNjODE0MmMyODM
Every request to a PROXY URL (e.g., "index.php?PHPSSESID=…", "proxy.php?PHPSSESID=…", or more commonly just "hxxp://current-proxy-domain/?PHPSESSID=…") contains the token of a RIG customer for the specific campaign. Basically, all customers using the same RIG exploit kit server share the PROXY URL. Before we discuss the PROXY core, let's take a closer look at the URI generated by the "api.php".
The URI is divided into 2 parts separated with the character "|". Here's the first part from our example:
njrMNruDMlmbScafcaqfH7sWaBLPThnJkpDZw-4
This encrypted string is actually a URL for a different server that handles requests to load an exploit and send it back to the victim's machine. Let's take a look at how this URL is generated:
To decrypt this content we need to use RC4 with the key and then use the function "base64url_decode". Here is the result of the string above, which is the VDS server that we will examine later on:
http://vdstomama[.]com/core.php
The second part of the URL structure is less exciting. The objective is to make sure the URL becomes invalid after a certain period of time - which is configurable by the RIG exploit kit admin; the default is 720 seconds (12 minutes). This technique is very effective because after 12 minutes the URL doesn't serve the exploits and is useless to security researchers trying to analyze such URLs.
The screenshot above describes the generation process of the token, which is a combination of the time, the user ID and the user login name all together with MD5 and later on with base64url_encode.
Now, let's get back to the place where the PROXY URLs are managed:
Only the RIG exploit kit administrator can manage this list. RIG customers have no control over it. The admin can bulk-load domains or load them one-by-one. This list functions as a queue using the first item (topmost) until anti-virus tools begin detecting it or it is no longer online.
On every RIG admin server, a scheduled task runs every 5 minutes to check the first active PROXY on the list:
PHP code to check the domains to be used as proxy servers
The domain is scanned by the "avdetect.com" service, and it is removed from the active list once it is detected as malicious. Additionally, if anti-virus vendors start to blacklist the PROXY server, then the RIG admin code will send the PROXY server a command to switch its assigned domain.
Proxy domains blacklisting code
The RIG administration server accesses the PROXY with a unique key along with the domain that should be removed. The domain is inserted into a blacklist file that is checked each time a victim is browsing the PROXY server.
The VDS Layer – Providing the landing page and exploits
VDS stands for Virtual Dedicated Server. VDS serves the role of an exploit generator. The main objective is to avoid detection by keeping those servers hidden from the world. According to records we've collected since August 2014, the RIG developers only used three different VDS servers.
First stage – fetching the landing page:
The first time the VDS is accessed results in the landing page content. The HTML/JS code itself is obfuscated using a function called CryptJS written by RIG's developers.
PHP function obfuscates the malicious JS code
After obfuscating the code, RIG's developers take extra caution by encrypting all of the data sent to the PROXY to avoid detection by IPS or anything monitoring the traffic.
PHP code serving the landing page (+ notify the admin server)
After sending the content back to the PROXY as depicted in the screenshot above, the VDS reports back to the RIG admin server about the exploit attempt.
Second stage – fetching the exploits:
The landing page will check if the browser supports Java, Flash or Silverlight. According to the results of the plug-in enumeration code, the victim's browser will request the respective exploits.
The PROXY receives the request from the victim machine and delivers it to the VDS.
In order to request the appropriate exploit, the victim's browser will issue another request with a new parameter named "req". For example, if the value is "swf", the VDS server will send back the Flash exploit. For example:
hxxp://[redacted].ga/proxy.php?req=swf&num=8454&PHPSSESID=njrMNruDMlmbScafcaqfH7sWaBLPThnJkpDZw-4|OTMxOGYwMjdkZTMxOGFmN2M5OWZkMDNjODE0MmMyODM
However, unlike the plug-in exploits that are only served if applicable, the Internet Explorer exploit is served without any prerequisites, already in the first VDS response along with the initial landing page.
Third stage – fetching the payload:
After it's exploited, the victim machine requests the payload using the parameter "req" with the value "mp3".
The VDS sends a request to the RIG admin server along with information about the victim machine and asks for the relevant payload that should be delivered.
The payload is pulled from the RIG admin server and encrypted using an RC4 key (a different key from the previous one) to avoid anti-virus detection.
Since this key is less important, it is sent to the victim machine during the exploitation phase. The executable itself is decrypted on the victim machine, written to the file system and then executed.
For example, if the successful exploit is CVE-2014-6332 then the decryption phase looks like this:
Payload decryption (part of the exploits)
RIG Administration Server
The RIG developers planned the infrastructure as a layered structure: the RIG admin server is basically nothing but a control panel and does not proactively exploit victim machines. Therefore, the RIG admin server can function for a long period of time behind a service such as CloudFlare, unlike the proxies, which are replaced regularly.
The admin server provides RIG customers with full control of their malware campaign and does not require any specialized knowledge of the back end. The RIG customer only needs to (1) figure out how to spread the infection URLs (typically by compromising web sites with large volumes of traffic, or malvertising) and (2) ensure the payload is stable.
Just like its competition, the RIG exploit kit provides complete statistics of the campaign's achievements.
The screenshot above displays the main statistics page of the exploit kit. The overall exploitation rate for this specific "flow" is 14.7%. You can notice that the overall exploitation is divided between Flash and Internat Explorer exploits. Specific CVEs include: CVE-0214-0311 in Flash; CVE-2013-2551 in versions 7, 8, and 9 of MSIE; and CVE-2014-6332 in Internet Explorer 10. Additional information reported includes countries targeted, browser versions and OS.
The business model
Here you'll see an advertisment for the RIG exploit kit on a Russian forum:
This advertisement is aimed at customers that want to distribute their malware (payload) using the RIG exploit kit. The criminals behind RIG also established a reselling model, whereby each reseller can have their own RIG admin panel from which their own customers will deploy infection campaigns.
Thus far our research has shown at least two large resellers accounting for over 250 customers combined. We can only assume there are additional resellers. Nonetheless, in comparison to the main RIG admin panel, which provided services to about 360 customers, it becomes evident that the reselling model almost doubled their profit. The data we examined accounts for the period of time between August 2014 and February 2015.
Multiplying 600 customers by $150 (the price per week of use), we estimate that the RIG exploit kit could be generating up to $90,000 per week. This rough estimate doesn't take into account operational expenses or customers that pay with a portion of their infections (similar to the Magnitude exploit kit's model), but it still shows that exploit kits can result in a very nice profit for the developers.
Trustwave customers using Trustwave SWG or Trustwave UTM are protected against RIG Exploit Kit without the need for any further updates.